Skip to content

fix(tui): clear answer editing state when selecting other options - #44240

Closed
aniruddhaadak80 wants to merge 2 commits into
anomalyco:devfrom
aniruddhaadak80:question-editing-state
Closed

fix(tui): clear answer editing state when selecting other options#44240
aniruddhaadak80 wants to merge 2 commits into
anomalyco:devfrom
aniruddhaadak80:question-editing-state

Conversation

@aniruddhaadak80

@aniruddhaadak80 aniruddhaadak80 commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Issue for this PR

Closes #44192

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Mouse handlers call selectOption()/selectTab() directly and bypass the enabled: !store.editing gate on the keybindings. So after selecting "Type your own answer" (editing mode), clicking a preset option (or another question tab) picks it but leaves store.editing stuck on true. At the confirm tab both binding sets then refuse Return - the editing set requires !confirm() and the normal set requires !store.editing - so the answers can never be submitted.

This clears editing when a preset option is picked or the tab changes. Selecting the custom row still enters edit mode as before; keyboard-only flows are unchanged since those keys are already gated off while editing.

How did you verify your code works?

  • Reproduced the flow locally in the TUI: select "Type your own answer", click a preset option, advance to confirm, Enter does nothing before this change and submits after.
  • Keyboard-only flow (escape out of editor, arrows, enter) behaves as before.
  • bun run typecheck clean in packages/tui; existing tui test suite shows no new failures.

Screenshots / recordings

Not a visual UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@Enough1122

Enough1122 commented Aug 23, 2026

Copy link
Copy Markdown

AI code review — automated review for reference, author can ignore or act on any point.

Correct root-cause analysis: mouse paths call selectOption()/selectTab() directly and bypass the enabled: !store.editing keybinding gate, so editing could stay true and permanently swallow Return on the confirm tab.

Details:

  1. In selectTab (packages/tui/src/routes/session/question.tsx, hunk @@ -100,6, added line 103), consider early-returning when index === store.tab. As written, any click that re-triggers selectTab for the current tab clears editing even when the user is actively typing a custom answer, discarding editor focus/state unintentionally.
  2. In selectOption (hunk @@ -118,6, added line 124), placement looks right — the custom-answer row must still end up with editing: true afterward, which relies on its branch running after this line. A brief comment pointing at that invariant (or an assertion in tests) would prevent future reordering regressions.
  3. No automated coverage was added for the store transition (editing cleared on tab/option change, kept for the custom row). Even a small unit test around these handlers would lock in the fix described in issue TUI: If "Type your own answer" in question/ask prompt was selected and then switched to a different option, the answers cannot be submitted #44192.

@aniruddhaadak80

aniruddhaadak80 commented Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the review - addressed in 1d7007028e:

  1. Same-tab guard: added if (index === store.tab) return at the top of selectTab. Verified safe for keyboard paths: left/right/tab bindings live in the enabled: !store.editing context, so they can't fire mid-typing; the wrap-around call with a single question is also unreachable while editing. The only same-tab caller during editing was the mouse click on the active tab header - now a no-op.

  2. Ordering invariant: added a one-line comment in the other() branch of selectOption noting it must return before any unconditional editing reset below it.

  3. Store-transition tests: skipped for now, with reasoning. The handlers are closures inside the route component; the only existing harness that mounts routes (createTestRenderer + full app boot) would require SDK question fixtures plus simulated mouse events - an integration test disproportionate to this fix, and more fragile than the logic it locks in. Happy to extract the tab/option state transitions into an exported pure module if maintainers prefer that seam; held off since it restructures working component internals.

@aniruddhaadak80
fix(tui): clear answer editing state when selecting other options
ad0e96d
@aniruddhaadak80
fix(tui): keep answer editor open when clicking the active question tab
f573c2b 
Review follow-up for anomalyco#44240: selectTab previously reset editing state even
when the clicked tab was already active, so re-clicking the current tab
header closed a custom-answer editor mid-typing. Navigation keybindings are
disabled while editing, so mouse clicks were the only path that could hit
this. Same-tab selection is now a no-op.

Also documents the ordering invariant in selectOption: the custom-answer
branch opens the editor and must return before any unconditional editing
reset.
@ishuowang ishuowang mentioned this pull request Sep 8, 2026
Closed
@github-actions

github-actions Bot commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

  • The PR was created more than 1 month ago
  • The PR had fewer than 2 positive reactions
  • Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

@github-actions github-actions Bot closed this Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

automated-pr-cleanup

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

TUI: If "Type your own answer" in question/ask prompt was selected and then switched to a different option, the answers cannot be submitted

2 participants

@aniruddhaadak80 @Enough1122